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Abstract 


Digital voice modes have become widespread on 
the amateur radio VHF and UHF bands. Many 
different formats are in use, but the one used in 
most public safety applications, P25, seemed to 
languish for lack of an inexpensive linking 
system. The P25 Network Exchange (P25NX) 
was designed to bring this mode into the fold and 
unite pioneering amateurs across the world. 


Introduction 


There are plenty of digital voice modes being 
used in Amateur repeaters. D-Star, DMR and 
System Fusion are the most well-known, but the 
sleeper is the granddaddy of them — Project 25! It 
should be noted that P25 phase 1, which is what 
P25NX supports, uses C4FM modulation, which 
a particular amateur system vendor has now 
adopted as a marketing term for their systems, 
making it appear it is something they invented — 
but it was around long before they starting using 
it. Some version of P25 is used by nearly every 
public safety agency with digital radios, and 
there is a wide variety of commercial radios 
available for this mode. Prices have been coming 
down as surplus gear hits the market when 
agencies upgrade to newer versions. Because of 
this, the most popular repeater that is used on P25 
became available for a reasonable cost. The 
Motorola Quantar. (Figure 1) 


The Quantar is a workhorse repeater, available in 
VHF, UHF, and 900 MHz versions usable on the 
amateur bands. Power outputs range from 25 
watts to 350 watts in the similar Quantro. The 
Quantar was never intended for wide area, 
multipoint linking, but this is exactly what was 
needed for Amateur Radio use. 
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Figure I -Motorola Quantar 


Getting to the root of the problem 


Some Quantars included a “V.24” interface for 
limited, site-to-site linking or receiver voting. 
The first problem was converting the Quantar 
data interface into something useable. V.24 is a 
standard that defines what is essentially a 
synchronous RS232 connection. In addition to 
the normal transmit, receive, and ground lines, 
there are two additional lines, one for transmit 
clock and one for receive clock. This port is 
available on an add-on card that was sometimes 
installed in the Quantar, but not as often as one 
would hope. The protocol for the data that runs 
over the V24 interface is High Level Data Link 
Control, or HDLC. HDLC was an early standard 
for data communications, but is not used much 
anymore. Fortunately, it was found that Cisco 
routers support this standard on their serial 
interface cards, using the Serial Tunneling 
(STUN) protocol...and old Cisco routers are 
very inexpensive on eBay. 


Next came decoding enough of the protocol to 
determine what was going on. Much of the credit 
for this work goes to John Yaldyn, ZL4JY. His 
years of experience with Quantars and expert 
deductive abilities really broke down the 
protocol and allowed for understanding of the 
connections from one Quantar to another. Before 
long, ZL4JY and a few others had figured out 
how to connect 2 routers together over the 
internet for point-to-point communications. That 
was pretty much the end of it for quite a while. If 


you wanted to do multipoint linking, you needed 
a very expensive Astro-Tac Comparator device, 
and enough line cards to accept connections from 
each repeater, plus a router or at least a serial card 
for each one. That gets expensive and 
cumbersome very quickly, although a few folks 
did do exactly that. One such system still links 
the Hawaiian Islands. 


In August 2014, I found all of the information 
which had been developed to that point on the 
“communications.support’” forum on_ the 
Internet (previously P25.ca), and used this to 
write a server software package that could act as 
a hub. This package, written in C# using Visual 
Studio, uses a central server which is configured 
to accept TCP/IP connections from each repeater 
site. From the repeater’s point of view, it’s 
connecting to one other repeater. The central 
server accepted the STUN connections from the 
routers, did some post-processing to pull out 
some of the more interesting pieces of data, and 
then reflected the data stream to all the 
connections except the sender. This was initially 
tested with ZL4JY, and then a few others. Before 
long, a post was  made_ on _ the 
communications.support forum announcing this 
breakthrough. Full worldwide linking was now 
possible. 


The reaction was swift and positive. Soon 10 
systems were online, then 20, and now over 30. 
While small compared to the number of D-Star 
or DMR repeaters, it is still finding new repeater 
owners who had no idea it was possible. 
Repeaters are located in many mainland US 
states plus Hawaii, and also internationally in 
Canada, Australia, New Zealand, France, 
Austria, and Germany. 


One problem mentioned earlier was the lack of 
availability of the V.24 board. Another forum 
user made a replacement circuit board, but it was 
very difficult to make work due to many tiny 
surface mount components. ZL4JY again came 


to the rescue with a simple one-chip design, and 
I designed a PC board for it. The complete 
assembled version of the board and adapter cable 
was placed for sale at a very reasonable cost on 
the P25NX website*, and over 50 units have been 
purchased to date. That problem was at least 
solved. 


The long road to Version 2 


Before long, people began asking about being 
able to segregate their traffic from the one 
worldwide talkgroup. A patch was put in to allow 
local traffic to take place, but it still “bled 
though” onto the network, causing interference 
with any conversations there. Several attempts 
were made to modify the software to support 
multiple talkgroups, but none were particularly 
successful. It was a difficult problem to solve, 
and lack of adequate time to work on it dragged 
the process out for well over a year. I knew that I 
wanted it to be very flexible — several of the other 
modes limited you to one talkgroup (room, 
reflector) with no easy way to dynamically 
switch between them. Others gave priority to 
larger talkgroups over smaller ones, which I 
believed is backwards from the way it should be. 


In version one, the system relies on a central 
server, which is a single point of failure, and a 
single person to maintain it. This was not 
desirable from a reliability or wife-happiness 
standpoint — the latter being more pressing. 
Something had to be done to distribute the 
network. One day while working on a project at 
work, I realized that that what I was doing could 
conceptually be applied to the network, and solve 
both problems at the same time. 


The multicast solution 


The solution is something called “IP Multicast”. 
This technology has been available for a long 
time, but is not supported over the internet for 
various technical reasons. Essentially, each 
endpoint tells its local router it wants to join a 
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particular multicast group. The routers talk to 
each other and have knowledge of which 
endpoints are on which groups. When a repeater 
site that has joined a particular group transmits, 
the network routes the data to the places it needs 
to go... no more central server is needed. In this 
system, the network does what it is meant to do — 
route data. As mentioned earlier, IP Multicast is 
not supported over the Internet. This is true, but 
DMVPN is. 


What is DMVPN? 


Dynamic Multipoint Virtual Private Network? is 
a method to establish “tunnels” over the internet, 
within which you can run other protocols. 
DMVPN in this case is set up as a mesh network, 
with geographically distributed hub routers 
through which traffic can flow. Single point of 
failure can be eliminated with two hub routers in 
each region, and each of them can take the traffic 
if there is a hub router failure. In addition, if 
configured correctly, some connections can even 
bypass the hubs and go directly from site to site. 
The best part of this is that intra-regional traffic 
stays within that region. A conversation between 
Germany and France stays within Europe. Inter- 
region talkgroups are routed though the US with 
high speed backbone links between the regional 
hub routers. While this is a complicated setup, it 
works very well. P25 Talkgroups are converted 
to multicast groups by using an inexpensive 
Raspberry PI or BeagleBone Black at each site. 


' http://www. project25.org/ 
? http://communications.support 
3 http://p25nx.com 


Bio: 


The PI also converts the unicast STUN data from 
the repeater to multicast and vice-versa. This 
approach is different than any other ham radio 
linking protocol that I know of. It eliminates 
reflectors, while allowing for almost unlimited 
talkgroups on demand. 
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Figure 2- Dynamic Multipoint VPN 
Where we are today 


Version one is still active and carries most of the 
network traffic at this time. Version two is still in 
beta test but slowly being rolled out to more 
users. A bridge between the two is online to ease 
the transition. This year, for the first time, the 
system was shown at the Dayton Hamvention in 
the TAPR booth. Several P25 inclined amateurs 
have come online, and more are working on it. 
The biggest surprise for people when they hear 
P25 for the first ttme? How good it sounds. 


4 http://www.cisco.com/c/en/us/support/docs/security- 
vpn/ipsec-negotiation-ike-protocols/41940-dmvpn.html 
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